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4) PROCEDE DE PAIEMENT ELECTRONIQUE PERMETTANT D EFFECTUER DES TRANSACTIONS LIEES A 
L* ACHAT DE BIENS SUR UN RESEAU INFORMAT1QUE. 

(57) Le procede utilise un reseau ouvert (10) sur lequel 
sont connectes des postes serveurs de marchands (20) et 
des postes clients (30) et comprend: 

- ('elaboration par un poste serveur de marchand d'un tic- 
ket de palement, concemant un achat envisage entre le 
marchand et un client, etcomportant des informations rela- 
tives au marchand, au client, a Pobjet de I'achat et a son 
prix; 

- la transmission du ticket de paiement via le reseau a un 
poste serveur de paiement (40); 

- la verification automatique par le serveur de paiement si 
le paiement du prix est autorise pour le client concerned soit 
par interrogation d'un compte client propre au client, tenu 
par le serveur de paiement, et destine au paiement des pe- 
tfts montants, soit par Interrogation sur un reseau bancalre 
(50) independent du reseau informatlque (10) pour les 
paiements de montants plus eleves, 

- si la verification est positive, ('elaboration par le serveur 
de paiement d'un bon ae caisse comportant au molns une 
partie des informations du ticket de paiement, et 

- la transmission du bon de caisse au serveur de mar- 
chand afin d'autoriser la realisation de I'achat. 
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La presente invention concerne un proced£ de paiemcnt Electronique 
5 permettant d'effectuer des transactions liees a I'achat de biens offerts par des 
marchands au moyen de services t61ematiques via un r£seau de telecommunication 
informatique ouvert sur lequel sont connects des postes serveurs de marchands et 
des postes clients. 

Par r£seau informatique ouvert, on entend ici un rdseau sur lequel des 

10 particuliers ou des entrcprises peuvent librement se connecter a la condition de 
disposer d'une adresse, par exemple le reseau "Internet". Les biens concernfe sont 
des produits ou des services, dont la fourniture est r£alisee hors du rdseau aprfcs la 
conclusion de la transaction, ou des biens immat6riels, tels que des informations, 
dont la fourniture peut etre realist via le r6seau informatique. 

15 Divers procedes de paiement electronique ont et6 proposes, certains 

6tant d€)h operationnels. 

Plusieurs procedes sont fondes sur une nouvelle representation de la 
monnaie. II s'agit d'une reprdscntation Electronique, quelquefois d6nomm6e jeton 
qui peut etre purement logicielle ou partiellement materielle, par exemple avec une 

20 carte a puce. Ces procEdEs impliquent la circulation de monnaie sur le r&eau 
informatique, ce qui pose des problemes difficiles de security vis-a-vis de la 
creation de fausse monnaie. 

D'autres procedds connus impliquent une relation directe avec une 
banque ou un rdseau bancaire, en particulier un reseau de carte de credit. II s'agit 

25 notamment des proc£d6s bien connus utilisant des terminaux points de vente relies 
a un circuit carte bancaire. II s'agit aussi des proc£des utilisant des cheques 
electroniques avec une signature electronique pour l'authentification de Tacheteur. 
Cest une forme de lettre d'engagement 6mise par un acheteur, remise au vendeur et 
acceptde et rcconnue par une banque. 

30 Les proc&tes qui impliquent a un moment ou un autre de la transaction 

une relation avec le systeme bancaire traditionnel et la mise en oeuvre d'une 
transaction dans ce systeme prdsentent des inconvfnients. Ainsi, les transactions 
dans le systeme bancaire ont un coGt rdel qui devient prohibitif lorsque le montant 
de I'achat est tits faible, par exemple consultation d'une base de donnEes. Or, les 

35 r&eaux informatiques sont bien adapt& a la vente de biens de faible valeur, 
principalement des biens d'information puisque la livraison du bien peut se faire 
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par le r&eau lui-meme. En outre, l'acces k un r&eau bancaire ou un r6seau de carte 
bancaire doit etre hautement prot6g£, ce qui exclut pratiquement la possibility d'un 
acc&s & travers un r&eau informatique ouvert, tel que Ie r6seau "Internet" sur lequel 
des acheteurs potentiels peuvent se connecter. 
5 L'invention a pour but de fournir un proc&te permettant d'6viter les 

inconv&iients des precedes connus, en particulier un proced6 permettant, sans 
circulation de monnaie Electronique, de r£aliser de fa^on simple et Gable des 
transactions liees h l'achat de biens sur un r6seau informatique, et ce aussi bien 
pour des biens de prix 61ev6 n£cessitant une autorisation par le systeme bancaire 
10 traditionnel, que pour des biens de faible ou tres faible prix. 

Ce but est atteint grace & un proc£d£ du type dlfini en tete de la 
prlsente description et comportant, conform&nent a l'invention, les Itapes de : 

- Elaboration par un poste serveur de marchand connect6 au rEseau 
d'une demande d'autorisation de transaction, ou ticket de paiement, concernant un 

15 achat envisage entre le marchand et un client, et comportant des informations 
relatives au marchand, au client, a l'objet de l'achat et a son prix, 

- transmission du ticket de paiement via le rcseau informatique & un 
poste serveur de paiement distinct des postes clients et serveurs de marchands, 

- verification automatiquc par ie serveur de paiement si le paiement du 
20 prix est autorisE pour le client concemE, la verification Etant effectuEe, selon le 

montant du prix a payer, soit par interrogation d'un compte client propre au client, 
tenu par le serveur de paiement, et destinE au paiement des petits montants, soit par 
interrogation sur un rEseau bancaire indEpendant du rEseau informatique, pour les 
paiements de montants plus ElevEs, 
25 - si la verification est positive, Elaboration par le serveur de paiement 

d'une autorisation de transaction ou bon de caisse comportant au moins une partie 
des informations du ticket de paiement, et 

- transmission du bon de caisse au serveur de marchand via le rEseau 
informatique, afin d'autoriser la realisation de l'achat. 

30 Ainsi, le procEdE selon ('invention est rcmarquable en ce qu f il 

n'implique ni la creation de monnaie Electronique, ni la circulation de monnaie 

Electronique sur le rEseau informatique. 

La gestion des transactions est effectuEe par un serveur de paiement 

qui seul peut accEder h un rEseau bancaire ou un r6seau de carte bancaire, et qui 
35 gere des comptes clients non bancaires sur lesquels des transactions de faibles 

montants peuvent etre effectives. 
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Le scrveur de paiemcnt gere egalement des comptes marchands non 
bancaires utilises pour les transactions de faibles raontants. Ainsi, lorsqu'un bon de 
caisse est transmis apres verification par interrogation d'un compte client tenu par 
le scrveur de paiement, le montant de I'achat est d€bit€ du compte client et crddit6 
5 sur un compte marchand propre au marchand concern^ et tenu par le serveur de 
paiement, ce qui n'entraine pas des coflts de traitement 61ev6s. 

Chaque client dispose d'une identity qui lui est propre pour pouvoir 
utiliser le procede de paiement. II doit egalement disposer d'un compte bancaire 
reel, de preference un compte utilisable au moyen du syst&me traditionnel des 

10 cartes bancaires. La verification par le serveur de paiement peut comprendre une 
phase prealable de validation de 1'identite du client a partir du contenu du ticket de 
paiement. La validation de 1'identite est une operation prdalable a l'acc&s 6ventuel 
au compte du client, si le montant de I'achat est faible, et/ou a 1'acces au reseau 
bancaire si le montant est plus £lev6. Le serveur de paiement comporte de 

15 preference des moyens, par exemple une base de donnees, permettant de 
memoriser les relations entre les identitds des clients utilises pour les transactions 
sur le reseau informatique et des identites bancaires (numeros de comptes 
bancaires ou numeros de cartes de credit) utilisees pour les transactions sur le 
reseau bancaire. On evite de la sorte la circulation d'identites bancaires sur le 

20 reseau informatique. 

Un mode de realisation de l'invention sera maintenant d£crit k titre 
indicatif, mais non limitatif, en reference aux dessins annexes sur lesquels : 

- la figure 1 est une vue gen6rale tres schematique d'un systeme de 
paiement eiectronique conforme a l'invention ; 

25 - la figure 2 est une representation sous forme d'un schema bloc d'un 

serveur de paiement du systeme de la figure 1 ; 

- la figure 3 illustre le deroulement des operations relatives a un achat 
au moyen du systeme de la figure 1 ; et 

- les figures 4A a 4C sont des organigrammes montrant tres 
30 schematiquement les operations effectuees par le serveur de paiement. 

Sur la figure 1 est represente de fa^on trfcs schematique un reseau de 
telecommunication informatique 10 sur lequel sont connectcs des postes serveurs 
de marchands 20, des postes clients 30 et au moins un poste serveur de paiement 
40. 

35 Le reseau informatique 10 est un reseau ouvert, par exemple le rfseau 

"Internet". 
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Les serveurs de marchands 20 sont des unites telles que celles 
couramment utilisees pour des serveurs tel6matiques connect es sur "Internet", par 
exemple des unites organises autour de machines "Unix" multiprocesseurs. 

Les postes clients 30 sont essentiellement des micro-ordinateure qui 
5 sont munis de moyens de connexion au r€seau "Internet" 10, par exemple sous 
forme d'intcrface "Web". Les serveurs de marchands 20 et de postes clients 30 
utilisent par exemple des logiciels connus sous la denomination "World Wide 
Web" (WWW) utilisant le protocole HTTP. 

Le serveur de paiement 40 (figure 2) comprend une unite frontale 41 

10 connect6e au reseau "Internet" 10 et une unite dorsale 42. L'unite frontale 41 a une 
architecture semblable a celle d'un serveur classique connect^ sur un r&eau tel 
qu'"Internet\ Uunite dorsale 42 comporte une unite de traitement 43 & un ou 
plusieurs processeurs, une base de donnles 44 relative aux marchands et clients 
abonnds au systfcme de paiement, un registre de transactions 45, une unite 46 

15 d'interface avec un reseau bancaire ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison similaire permettant de relier entre eux les 
diff&ents constituants de Punite dorsale 42. Une liaison s6curis6e 48 permet une 
communication bidirectionnelle entre l'unit£ frontale 41 et l'unite de traitement 43. 
La communication avec le reseau informatique 10 est controlee par l'unite frontale 

20 41 tandis que la gestion de la base de donndes 44 ainsi que le contrdle de la 
communication avec le reseau bancaire 50 sont assures par l'unit6 dorsale 42. 

La base de donn6es 44 contient des informations relatives aux clients 
et aux marchands abonnds au systfcme de paiement. Pour chaque client, la base de 
donndes 44 contient 1'identite syst&me du client Qd, identity regue lors de 

25 Tabonnement au systfcme, un compte de client, ou porte monnaie eiectronique 
PME destind au paiement de faibles montants, une identity bancaire telle que 
numlro de compte bancaire r6el ou numdro de carte de credit ainsi 
qu'eventucllement une clef d'acces ou mot de passe propre au client. Pour chaque 
marchand, la base de donndes 44 contient 1'identite systfeme du marchand Mid, 

30 identity regue lore de l'abonnement au systeme, un compte de marchand, ou tiroir— 
caisse eiectronique TOE destine h l'encaissement des faibles montants et une 
identite bancaire telle que num£ro de compte bancaire reel. 

La figure 3 illustre schematiquement differentes etapes d f une 
transaction portant sur un achat d'un bien par un client abonne a un marchand 

35 abonne. II peut s ! agir d'un bien materiel dont la livraison au client sera effectuee 
reellement aprfcs conclusion de la transaction ou d'un bien immateriel tel que de 
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reformation qui peut etre fournie au client par le rdseau informatique dts le 
paiement 6Iectronique effectu6. 

(1) Consultation par lc client 

Par connexion sur le r&eau "Internet" 10, un client peut consulter en 
5 ligne le catalogue ou la "vitrine" d'un marchand par acces au serveur 20 du 
marchand et visualisation sur l'6cran du poste client 30. Sur presentation de 
Tidentitfi CId du client, le serveur du marchand peut presenter au client des 
conditions financi&res particul&res (par exemple une remise). 

(2) Pemen fa d'gctwt 

10 Le choix du client £tant arrets sur un bien O, il est transmis au serveur 

du marchand sous forme d'un message contenant une identite Old du bien et 
Tidentitg CId du client. Lorsque cela est n6cessaire, par exemple pour la livraison 
ultlrieure du bien choisi, des informations compl£mentaires (par exemple adresse 
et horaire de livraison) peuvent etre demandles au client en lui adressant via le 

IS r£seau informatique un formulaire a completer. 

Dans le cas ou l'achat envisage represcnte un montant 6lsv6 ou est 
soumis a des conditions legates, une authentification prdalable du client peut etre 
souhaitle. Comme on le verra en detail plus loin l'authentification d'un client est 
effectu^e par le serveur de paiement 40. Aussi, une demande d'authentification 

20 provenant d'un marchand est 6mise avantageusement sous la forme d ! un ticket de 
paiement de valeur nulle qui est transmis au serveur de paiement par le r6seau 
informatique via le poste client et, en cas d'authentification positive, provoque le 
retour d'un bon de caisse du serveur de paiement au serveur marchand, toujours via 
le poste client. Les procedures d'&ablissement d'un ticket de paiement et de renvoi 

25 d'un bon de caisse sont d£crites plus en detail ci-apres. 

La demande d'achat £mise par le client peut porter sur un seul bien ou 
sur plusieurs biens a foumir de fa$on groupie : "achat panier". 

(3) Elaboration to ttemanto fa pafcment 

En rlponse h une demande d'achat, le serveur marchand llabore une 
30 demande de paiement qui peut comprendre les informations suivantes : 

- Identity Mid du marchand, 

- Description du bien command^, ou de chacun des biens du panier, en 
cas d'achats groups, 

- Type de transaction (simple ou panier), 
35 - Identit6 CId du client, 

- Identite Old du bien ou de l'ensemble des biens du panier, 
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- Prix de l'objct Old, 

if 

- TVA (si applicable), 

- Date et heure de remission du ticket de paiement (horodatage par le 
servcur marchand), 

5 - Dur6e de validity du ticket de paiement, 

- Numdro de scrie dans le registre des ventes du marchand (notamment 
dans le cas ou la transaction a comportl une 6tape prdalable d'authentification). 

L'ensemble des informations ci-dessus est encodee dans une chaine 
d'octets qui constitue la chaine opaque d'un ticket de paiement (ou URL de 
10 commande de bien, URL 6tant les initiates de "Uniform Resource Locator" ou 
Local isateur de Ressource Uniforme utilise dans les logiciels WWW avec 
protocole HTTP) : 

URL http : < SP> < descriptif de la commando , 
ou SP est Tadresse "Internet" du serveur de paiement. Le ticket de paiement est 
15 adressl au poste client. II est compl&l par deux ancres qui pcrmettent au client soit 
de l'annuler, soit de le confirmer. 

(4^ Envoi de 1'ordre de paiement 

L'ordre de paiement est transmis au serveur de paiement simplement 
par validation par le client de l'URL de demande de paiement, de sorte que le ticket 
20 de paiement ne fait alors que transiter par le poste client. 

(S) Emission bon wisse 

Sur reception d'un ordre de paiement, le serveur de paiement 40 le 
decode et proc&de & l'authentification du client et recherche si le paiement peut etre 
autorisl avant de retoumer un bon de caisse ou un refus de paiement. 

25 Les operations d'authentification de client et d'autorisation de paiement 

seront d6crites plus loin en detail en reference a la figure 4. 

Lorsque les verifications effectu£es ne permettent pas d'autoriser le 
paiement, une notification de refus motiv6e est adressee au client par le serveur de 
paiement (par exemple compte insuffisamment approvisionne, depassement d'un 

30 seuil autorise pour le client, ...) 

Lorsque les verifications effectudes permettent d ! autoriser le paiement, 
les informations contenues dans le ticket de paiement sont compl6t€es avec un 
num£ro de s£rie dans le registre des transactions 45, une estampille horaire, une 
dur£e de validity (typiquement quelques dizaines de secondes) et le sceau du 

35 serveur de paiement constituant une information de certification. L'ensemble de 
ces informations, Ivehtuellcment apres signature num£rique avec une clef privle 
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du serveur de paiement garantissant la validity et 1'integrite de I'autorisation de 
paiement, est encode dans une chaine d'octets qui constitue la chaine opaque d'un 
bon de caisse ou URL de livraison : 

URL http : <M> <descriptif du bon de caisse> , 
5 ou <M> est Tadresse "Internet" du marchand. 

(6) P<?m<w to to livraison 

Le bon de caisse est transmis au serveur du marchand via le poste 
client. Ceci peut etre effectu6 automatiquement par le logiciel implant6 au poste 
client en utilisant la possibility de re-routage des URL. Apres ddcodage du bon de 
10 caisse, la validite du bon de caisse est v6rifi6e par le serveur marchand avant 
d'autoriser la livraison du bien. Cette verification consiste a contrdler la clef priv& 
6ventuelle du serveur de . paiement, a verifier que la dur6e de validity n'est pas 
6coul6e, et a rapprocher le contenu du bon de caisse avec celui de la demande de 
paiement. 

15 (7) Livraison du bien 

Lorsque le bon de caisse est valid£ par le serveur du marchand, celui- 
ci peut effectuer la livraison directe sur le poste client, dans le cas de bien 
d'information, ou adresse au poste client un document permettant le retrait du bien 
et prlcisant notamment le lieu de livraison et le nom du r£cipiendairc. 

20 On notera que, dans le cas d ! un achat group6 (panier), il y a creation 

par le serveur du marchand d'un objet avec affectation d'une identit6 unique. Cet 
objet est la liste des URL de chacun des biens du panier. Cest cet objet qui est 
indique dans l'URL de commande de bien et qui permettra d'enregistrer le detail 
des biens achet£s dans le registre de transaction du serveur de paiement. 

25 Les figures 4A h 4C montrent les operations effectufies par le serveur 

de paiement 40 en r£ponse a la r6ception d'un ordre de paiement. 

Dans l ! unit£ frontale 41 (figure 4A), l'ordre de paiement est d£cod6 
(6tape 61) et sa validity est examinee (test 62) notamment du point de vue de la 
durde de validity. Si le r&ultat de I'examen est ndgatif, une notification de refus est 

30 envoy6e au poste client (€tape 63). 

Si le resultat de I'examen est positif, il est proc£d6 ensuite k une 
authentication du client (6tape 64), le detail de cette operation £tant d6crit plus 
loin en reference h la figure 4C. Si l'authentification est negative (test 65), une 
notification de refus est envoyde au client (6tape 63). Si elle est positive, l'ordre de 

35 paiement (dventuellement limits & l'identitf CId du client, k l'identit6 Mid du 
marchand, et au prix) est transmis via la liaison 68 a l'unit6 dorsale 42 du serveur 



2733068 



8 



de paiement (etape 66). La liaison 48 est une liaison s£curis6e interdisant Vaccts h 
l'unit6 dorsale a toute personne se connect ant sur le r&eau 10. 

L'unitl frontale 41 reste alors en attente d'un retour de I'unitl dorsale 
autorisant ou non le paiement (6tape 67). Si le paiement n'est pas autorisl, (test 68), 
5 une notification de refus est envoy6e au poste client (6tape 63). Si le paiement est 
autorisi, un bon de caisse est 61abor6 (6tape 69), utilisant les informations 
enregistr6es a l'6tape 62. Le bon de caisse est enregistr£ dans une m&noire de 
1'unitl frontale 41 (6tape 70) et est adress£ au serveur du marchand via le poste 
client (6tape 71). 

10 Au niveau de Punitfi dorsale 42 (figure 4B), a la reception d'un ordre de 

paiement authentifi6, il est examine si celui-ci doit etre autorisi a partir du compte 
client PME ou par interrogation sur le rdseau bancaire 50. A cet effet, le prix est 
compart a un seuil minimum (test 72). Ce seuil est par exemple de quelques 
dizaines de francs. 

IS Si le seuil est depass£, une demande pour effectuer l'oplration de 

paiement est lancle sur le rlseau bancaire (6tape 73) en utilisant l'identitg bancaire 
correspondant a I'identitl CId du client, telle qu'elle ressort de la consultation de la 
base de donnees 44. A la rdception de la r^ponse positive ou negative (6tape 74), 
celle-ci est transmise a I'unit6 frontale 41 (6tape 75). 

20 Si le seuil n'est pas dlpass6, le paiement peut etre effectu6 a partir du 

compte PME du client. 

A cet effet, il est examin6 si le compte est suffisamment approvisionne 
(test 76). Dans la negative, un refus d'autorisation de paiement, c'est-a-dire une 
r€ponse negative, est renvoy^e a l'unit£ frontale (6tape 75). Dans raffirmative, le 

25 compte PME du client est debits du prix et le compte TCE de marchand 
correspondant h Tidentitfi Mid est cr6dit6 du meme montant (&ape 77), la 
transaction est inscrite dans le registre dcs transactions 45 (etape 78) et 
Valorisation de paiement, c ! est-a-dire une r£ponse positive est transmise a l'unit6 
frontale 41 avec 1'indication du numero de s£rie de 1'inscription dans le registre de 

30 transactions (6tapc 75). 

La procedure d'authentification (figure 4Q & I'etape 64 de la figure 4A 
comprend 1'envoi s6curis£ au poste client d'une demande de c\6 d'acc&s, ou mot de 
passe (6tape 641). A la reception s£curis& de la c\6 d'accfcs (Itape 642), une 
comparaison est effectude avec une information correspondante contenue dans la 

35 base de donnees 44 (test 643). 
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Si la comparison est negative, et qu'un nombre maximum de 
tentatives infructueuses n ! a pas 6ti atteint (test 644), on retourne a l'&ape 641. Si ce 
nombre maximum est atteint, l'absence d'authentification est constats, une alerte 
est produite (Itape 645) et une rlponse negative est 61abor6e (ctape 646). L'alerte 
5 peut consister en une annul at ion du compte PME ou en une surveillance de celui- 
ci afin de d€tecter de nouvelles tentatives d'utilisation. Si le test 643 est positif, 
l'authentification est enregistr£e (6tape 647) et une rdponse positive est 61abor6e 
(6tape 648). 

Des techniques de chiffrement permettant la transmission securis£e 
10 ^informations num6riques sur r£seau informatique, notamment pour la demande 
d'envoi de c\6 d'acces et l'envoi de celle-ci, sont bien connues. 

La procedure d'authentification permet d'effectuer une authentication 
prealable d'un client dans le cas ou celle-ci est ndcessaire avant l'&ablissement 
d'une demande de paiement par le serveur du marchand. Pour cette 
15 authentification, il suffit alors en effet de crfer un ticket de paiement dans lequel le 
prix indique est nul, comme indiqul plus haut. 

L'enregistrement des bons de caisse dans l'unit£ frontale permet aux 
clients et aux marchands de proc£der a des controles et d ! en obtenir 6ventuellement 
des copies. L'enregistrement des transactions dans l'unit£ dorsale permet d'en 
20 conserver une trace en cas, par exemple, de contestation entre un client et un 
marchand. 

Les comptes clients PME g€iis par le serveur de paiement ont en 
principe un montant plafonn£. Us ne sont pas r6mun6r6s, le systfcme de paiement se 
trouvant en dehors du monde bancaire. Un rdapprovisionnement de son compte 

25 PME par un client peut etre effectu6 a partir de son compte bancaire, par ordre 
donn6 a son etablissement bancaire. 

Les comptes marchands TCE gerds par le serveur de paiement sont 
associds a des comptes bancaires rdels des marchands dans lesquels ils sont vid6s 
par exemple quotidiennement. 

30 Bien que Ton ait decrit ci-avant un mode de mise en oeuvre d'un 

proc&te selon 1'invention dans un environnement "Internet" et avec des logiciels 
WWW utilisant le protocole HTTP, l'homme de Tart comprendra ailment que le 
proced6 peut etre mis en oeuvre avec un rdseau informatique autre qu'"Inteniet" ou 
encore avec des logiciels serveur marchand et client n'utilisant pas le protocole 

35 HTTP de WWW. En outre des proc&tes d'authentification s£curis6s mettant en jeu 
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des dispositifs matenels tels que lecteur de carte a puce ou moyen de 
reconnaissance d'empreinte vocale pourront etre prevus a la place de clefs d'acces. 
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REVENDICATIONS 

1. Precede de paiement eiectronique pour effectuer des transactions Hies 
h l'achat de biens offeits par des marcbands a des clients via un reseau de 
telecommunication informatique ouvert sur lequel sont connect es des postes 

5 serveurs de marchands et des postes clients, caracterise en ce qu'il comprend les 
etapes de : 

- Elaboration par un poste serveur de marchand connect^ au reseau 
d'une demande d'autorisation de transaction, ou ticket de paiement, concernant un 
achat envisage entre le marchand et un client, et comportant des informations 

10 relatives au marchand, au client, h l'objet de l'achat et a son prix, 

- transmission du ticket de paiement via le reseau informatique a un 
poste serveur de paiement distinct des postes clients et serveurs de marchands, 

- verification automatique par le serveur de paiement si le paiement du 
prix est autorise pour le client concernd, la verification etant effective, selon le 

15 montant du prix h payer, soit par interrogation d'un compte client propre au client, 
tenu par le serveur de paiement, et destine au paiement des petits montants, soit par 
interrogation sur un reseau bancaire independant du reseau informatique, pour les 
paiements de montants plus Aleves, 

- si la verification est positive, elaboration par le serveur de paiement 
20 d'une autorisation de transaction ou bon de caisse comportant au moins une partie 

des informations du ticket de paiement, et 

- transmission du bon de caisse au serveur de marchand via le reseau 
informatique, afin d'autoriser la realisation de l'achat. 

2. Procede selon la revendication 1, caracterise en ce que lorsqu'un bon 
25 de caisse est transmis aprfcs verification par interrogation d'un compte client tenu 

par le serveur de paiement, le montant de l'achat est debit£ du compte client et 
credite sur un compte marchand propre au marchand concerne et tenu par le 
serveur de paiement. 

3. Procede selon Tune quelconque des revendications 1 et 2, caracterise 
30 en ce que la verification par le serveur de paiement comprend une phase pr6alable 

d'authentification du client. 

4. Procede selon la revendication 3, caracterise en ce que 
1'authentification est rdalisee par reconnaissance d'une clef d'acc&s transmise par le 
reseau informatique du poste client au serveur de paiement. 

35 5. Procede selon Tune quelconque des revendications 1 a 4, caracterise en 

ce qu'il comprend l'eiaboration par le serveur de paiement d'un bon de caisse 
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comportant au moins une partie des informations du ticket dc paiement ct une 
information de certification. 

6. Proc£d6 selon Tune quelconque des revendications 1 a 5, caract6ris£ en 
ce qu'il comprend la memorisation par le serveur de paiement des transactions 

5 autoris£es, par stockage d'au moins une partie du contenu des bons de caisse. 

7. Procede selon Tune quelconque des revendications 1 a 6, caracterise en 
ce que le ticket de paiement est transmis du serveur du marchand au serveur de 
paiement par I'interm6diaire du poste client. 

8. Procede selon Tune quelconque des revendications 1 a 7, caracterise en 
10 ce que le bon de caisse est transmis du serveur de paiement au serveur du 

marchand par rinterm6diaire du poste client. 

9. Systeme de paiement eiectronique pour effectuer des transactions H6es 
a l'achat de biens offerts par des marchands h des clients via un reseau informatique 
ouvert, le systfeme comportant des postes clients et des postes serveurs de 

15 marchands pouvant etre connects sur le reseau ouvert, 

systfeme caracterise en ce qu'il comporte en outre au moins un poste serveur de 
paiement distinct des postes clients et serveurs de marchands et comprenant : 

- une unit6 frontale munie de moyens de connexion au rcseau ouvert, 

- une unite dorsale munie de moyens de connexion a un rcseau 
20 bancaire independant du reseau ouvert, 

- des moyens de communication entre les unites frontale et dorsale, 

- des moyens de memorisation de comptes de clients, de comptes de 
fournisseurs, et 

- des moyens de traitement pour, en rlponse a la reception par 1'unite 
25 frontale d'une demande d'au tori sat ion de transaction ou ticket de paiement, 

concernant un achat envisage entre un marchand ct un client, verifier si le paiement 
du prix est autorise pour le client concern^ par interrogation du compte du client 
ou du reseau bancaire et, si la verification est positive, eiaborer une autorisation de 
transaction, ou bon de caisse afin de ia transmettre sur le reseau ouvert via 1'unite 
30 frontale. 

10. Systeme de paiement selon la revendication 9, caracterise en ce que le 
serveur de paiement comprend des moyens de memorisation des transactions 
autorisees. 
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